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t  the  turn  of  this  century,  Secretary  of  De¬ 
fense  Donald  Rumsfeld  identified  a  prob¬ 
lem  with  DoD's  system  of  developing 
and  delivering  joint  warfighting  capabili¬ 
ties:  There  wasn't  one.  The  Services  were 
generating  requirements  for  weapon 
systems  and  programs  they  wanted, 
but  the  combatant  commanders  (who, 
under  federal  law,  are  actually  authorized 
to  command  multiple  Service  forces  in 
military  operations)  had  no  voice.  The 
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system  that  emerged  to  correct  this  deficiency  was  called 
the  Joint  Capabilities  Integration  and  Development  System 
(JCIDS). 

As  DoD  policy,  JCIDS  has  certainly  helped  to  correctly  align 
the  requirements-generation  process  with  the  way  the  mili¬ 
tary  actually  fights  as  a  joint  force.  But  JCIDS  is  more  than 
policy;  it  is  also  an  analytical  process.  The  inventors  of  JCIDS, 
in  effect,  asserted  a  theory  of  requirements  development  and 
acquisition  that  has  come  to  be  known  generally  as  capabil- 
ities-based  analysis. 

The  problem  is  that  capabilities-based  reality  has  never  quite 
lived  up  to  capabilities-based  theory. 

An  assumption  of  the  capability-based  approach  is  that  one 
should  be  "agnostic"  with  respect  to  specific  solutions— the 
theory  being  that  this  frees  the  analysis  from  potential  bias 
toward  particular  commercial  or  developmental  solutions. 
The  idea  is  to  evaluate  the  military  problem  from  a  functional 
standpoint.  First,  you  have  to  articulate  what  success  looks 
like  for  the  military  task  set  in  question.  Then  you  have  to 
figure  out  what  capabilities  are  needed  to  accomplish  the 
military  task.  Finally,  you  compare  your  existing  capabilities 
against  the  functional  standard  to  see  if  there  is  a  match. 
If  the  capability  is  less,  you  have  a  "capability  gap."  If  it  is 
greater,  you  have  an  "overmatch." 

This  gap-analysis  approach  is  the  beginning  of  the  JCIDS 
process.  Gap  analysis  only  examines  the  need  for  a  capa¬ 
bility.  One  must  then  conduct  a  capabilities-based  solution 
analysis— again,  scrupulously  attempting  to  be  agnostic  with 
respect  to  potential  solutions,  to  avoid  pre-selecting  a  spe¬ 
cific  capability. 

But  a  problem  with  this  approach  emerges  even  before  you 
can  say  "capabilities-based  analysis."  The  notion  of  military 
capability  is  difficult  to  translate  from  theory  to  practice.  Such 
a  term  briefs  well,  but  it  is  very  difficult  for  military  command¬ 
ers  to  consider,  for  example,  "force  employment— ground" 
as  some  kind  of  generic,  kinetic  capability.  What  they  want 
are  the  things  they  know:  tank  battalions,  combined-arms 
task  forces,  long-range-reconnaissance-patrols,  etc.  (Hav¬ 
ing  said  this,  let  me  be  clear  that  I  am  not  critical  of  the  use 
of  the  word  "capability"  as  a  term  to  describe  a  range  of  re¬ 
lated  warfighting  tools  or  assets— just  the  notion  that  one  can 
analyze  capability  in  the  generic  sense  in  any  rigorous  way.) 

Capabilities-based  theory  tells  us  that  capability  should 
be  fungible— that  is,  one  should  be  able  to  have  some  way 
of  providing  equivalent  capability  using  either  materiel  or 
non-materiel  means.  The  problem  is  that  to  date,  no  one 
has  been  able  to  adequately  quantify  a  capability  in  terms 
of  "units  of  capability,"  such  that  we  can  compare  the  rela¬ 
tive  effectiveness  of,  say,  an  infantry  battalion  to  an  aerial 
bombardment  in  terms  of  providing  equivalent  force-em¬ 
ployment  capability. 


That  is  why  so-called  "gap  analyses"  are  nothing  more 
than  highly  subjective,  qualitative  statements  that  sound 
like,  "The  joint  force  commander  lacks  the  capability  to  do 

_ ."  There  is  nothing  rigorous  or  analytical  about  this, 

so  why  beat  around  the  bush?  If  the  joint  force  commander 
wants  more  "x,"  just  ask  for  more  "x"!  Let's  not  pretend 
that  we  have  to  be  "solution  agnostic"  if  there  is  a  known 
solution  that  works  now  or  is  in  development. 

If  the  notion  of  kinetic  (force  employment)  capabilities  is 
problematic,  the  situation  is  even  more  confusing  when  dis¬ 
cussing  the  relatively  ambiguous  notion  of  command  and 
control  (C2)  capabilities.  For  the  most  part,  these  capabili¬ 
ties  are  associated  with  tools  that  assist  the  commander 
and  his  staff  in  the  planning  and  execution  of  those  plans 
through  various  communication  networks  and  the  main¬ 
tenance  of  the  continuous  awareness  of  both  friendly  and 
enemy  situations.  The  "things"  providing  these  capabili¬ 
ties  are  usually  software  applications.  Like  anything  else, 
the  complete  "capability"  requires  a  trained  operator  and 
a  physical  infrastructure,  but  we  have  come  to  associate  a 
"capability"  with  the  "system"  or  computer  program  that 
provides  it. 

Unlike  many  other  military  capabilities,  such  as  weapon 
systems  or  strategic  lift  assets,  which  are  platform-  and 
program-centric  and  follow  a  predictable  operational  life 
cycle,  information  technology  (IT)-based  capabilities,  such 
as  those  in  the  C2  domain  are  based  on  technologies  whose 
state  of  the  art  changes  exponentially  relative  to  time.  Be¬ 
cause  there  is  no  traditional  engineering  and  manufacturing 
infrastructure  required,  IT-based  tools  can  (or  should)  be 
rapidly  developed,  tested,  and  fielded.  Unfortunately,  while 
the  joint  requirements  generation  process  has  attempted  to 
become  more  flexible  and  agile  through  JCIDS,  the  Defense 
Acquisition  System  (DAS)  establishment  treats  the  realiza¬ 
tion  of  IT  capabilities  in  the  same,  ponderous,  program¬ 
centric  way  it  obtains  other  capabilities.  This  fact,  combined 
with  the  failure  of  so-called  "capabilities  based"  approaches 
to  acquisition,  suggests  an  alternative  approach  is  needed; 
at  least  with  respect  to  the  C2  functional  area. 

We  offer  the  following  propositions  to  help  summarize  the 
current  situation  and  begin  to  move  toward  the  next  genera¬ 
tion  of  capability  development  and  delivery  (with  particular 
reference  to  C2  capabilities): 

•  The  theory  of  capability  delivery  based  on  the  notion  of  fun- 
gibility  of  capabilities  and  ". solution  agnosticism"  is  unsup¬ 
ported  by  either  academic  investigation  or  practical  utility. 

The  definition  of  "capability"  in  the  literature  suggests 
that  capabilities  are  combinations  of  both  "ways  and 
means."  Ways  refers  to  the  non-materiel  components 
of  capability  such  as  doctrine,  organization,  training; 
means  refers  to  the  materiel  component. 
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While  the  joint  requirements  generation 
process  has  attempted  to  become  more 
flexible  and  agile  through  JCIDSr  the  Defense 
Acquisition  System  (DAS)  establishment 
treats  the  realization  of  IT  capabilities  in  the 
same,  ponderous,  program-centric  way  i 
it  obtains  other  capabilities.  M 


Attempts  to  translate  the  above  concept  of  "capability" 
into  a  practical  evaluative  system  to  compare  alternative 
capabilities  have  not  been  successful. 

•  So-called  "portfolios  of  capability"  are  an  unrealistic  and 
unworkable  fiction  and  should  be  abandoned. 

Portfolio  management,  by  definition,  implies  owner¬ 
ship  of  the  portfolio  elements.  What  is  in  one  person's 
portfolio  cannot  also  be  in  someone  else's  portfolio.  An 
experiment  in  "capability  portfolio  management,"  which 
began  in  2006,  established  "capability  portfolios"  in  an 
attempt  to  adopt  commercial  industry  best  practices. 
However,  in  many  cases,  programs  that  are  in  one 
portfolio  are  also  claimed  by  another.  For  example,  Net- 
Centric  Enterprise  Services  (NCES)  is  claimed  by  both 
the  Net-Centric  and  the  C2  portfolios. 

Industry  uses  portfolio  management  to  reduce  risk  and 
maximize  return  on  investment.  Since  the  unit  of  mea¬ 
sure  (money)  is  common  to  such  portfolios,  assessment 
of  portfolio  elements  is  a  straightforward  exercise.  This 
is  not  the  case  with  capability  portfolios,  in  which  one  is 
trying  to  compare  two  or  more  capabilities  absent  any 
kind  of  capability  metric. 

•  Attempts  to  create  analytical  tools  that  purport  to  produce 
rigorous  capability  analyses  supportive  of  "portfolio  deci¬ 
sions"  are  an  exercise  in  futility  and  should  be  discontinued. 

The  previous  two  propositions  lay  out  the  case  that, 
unless  and  until  sufficient  theoretical  work  is  done  to 
undergird  the  concept  of  capability  based  analysis,  it  is  a 
waste  of  money  and  time  to  attempt  to  build  capability- 
based  analysis  "tools." 


Over  the  past  several  years,  a  great  deal  of  time  and 
money  was  spent  developing  three  prototype  tools  that 
were  advertised  as  being  key  to  supporting  C2  capability 
portfolio  decisions.  In  one  case,  the  tool  was  based  on  the 
DoD  Architecture  Framework  (DoDAF),  a  labor-intensive 
process  of  displaying  military  concepts  via  operational 
and  system  "views."  In  another,  the  analytical  centerpiece 
was  a  "mapping"  of  C2  systems  to  system  functions;  the 
goal  being  to  create  a  "Rosetta  Stone"  to  link  military 
functions  with  tools.  Lastly,  an  attempt  was  made  to 
develop  a  complex  visualization  tool  based  on  something 
called  Joint  Mission  Threads  (JMT).  A  JMT  is  a  complex, 
detailed  model  designed  to  thoroughly  describe  a  military 
mission  from  start  to  finish,  to  show  how  supporting  C2 
systems  would  be  used  to  support  such  a  mission. 

A  problem  with  all  three  of  these  tools  is  that  their  de¬ 
velopers  assumed  that  simply  breaking  up  the  military 
problem  into  more  granular  pieces  would  allow  a  clear 
alignment  with  functions  that  can  be  provided  by  C2 
systems.  However,  simply  discovering  that  a  C2  system 
performs  a  function  that  supports  a  military  task  set 
provides  no  information  about  the  degree  to  which  that 
system  performs  the  function— something  that  is  key  if 
one  is  going  to  make  a  portfolio  decision  (retaining  one 
system  and  eliminating  another). 

A  better  approach  would  be  to  take  the  time  and  effort 
to  build  a  value  model  that  captures  what  is  really  im¬ 
portant  to  DoD  decision  makers  and  stakeholders  and 
apply  such  a  model  to  the  assessment  of  potential  C2 
solutions.  This  technique,  referred  to  as  value-focused 
thinking,  or  VFT,  has  been  usefully  applied  in  numerous 
portfolio-based  decision  problems  throughout  DoD. 
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•  Perhaps  more  important 
than  so-called  capabil¬ 
ity  analysis  is  setting 
the  conditions  and 
structures  for  rapid  and 
agile  delivery  of  needed 
weapon  systems  and 
other  capabilities.  Some 
changes  could  include: 

—  Reform  of  IT  acqui¬ 
sition.  The  acquisi¬ 
tion  of  software- 
based  capabilities 
must  be  freed  from 
the  traditional  DoD 
5000  series  model. 
Such  IT  acquisi¬ 
tion  reform  would 
include  new  ap¬ 
proaches  to  funding 
the  development 
and  sustainment  of 
software-based  ca¬ 
pabilities  using  such 
resourcing  schemes 
as  e-commerce  and 
software  as  a  ser¬ 
vice. 
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From  Black  Ops  to  Black  Tie, 

Alpha  Company  looks  smashing  in  this 
season's  high-tech  combat  formalwear  - 
fighting  for  freedom  AND  fabulousness! 


Emphasis  on  net- 
centricity.  DoD  pol¬ 
icy  must  strengthen 
the  requirement  for 
common  enterprise 
architectures  based 

on  software  services  and  cloud  computing  and  confor¬ 
mance  to  the  Global  Information  Grid  (GIG)  2.0  model. 


in  the  meantime,  we  should  apply  our  collective  intellectual 
potential  toward  the  more  pressing,  practical  need  to  create 
a  robust  and  flexible  capability  delivery  system. 


—  Centralization  of  standards,  policies,  and  governance, 
and  decentralization  and  diffusion  of  capability  devel¬ 
opment  in  conformance  with  said  standards.  Rapid  and 
agile  development  and  delivery  of  IT  capabilities  is  more 
likely  in  such  an  environment  than  mired  in  traditional, 
large  "software  development  houses"  or  materiel  devel¬ 
opers. 

Years  ago,  I,  too,  became  excited  at  the  prospect  of  developing 
truly  analytically  rigorous  capabilities-based  approaches  to 
meeting  warfighter  needs.  The  operations  research  commu¬ 
nity  devoted  whole  symposia  to  the  discussion  of  capabilities- 
based  approaches.  But  the  holy  grail  of  a  complete  theory  of 
capabilities-based  analytics  was  never  attained.  We  may  yet 
achieve  a  level  of  capability  analysis  that  yields  to  a  quanti¬ 
tatively  rigorous  approach  that  will  withstand  the  scrutiny  of 
gatekeeper  organizations  like  the  office  of  Cost  Assessment 
and  Program  Evaluation  at  the  Pentagon  (OSD  [CAPE]).  But 


Getting  the  parameters  of  this  capability  development  system 
right  is  more  important  than  maintaining  capabilities-based 
ideological  purity.  This  means  admitting  that  the  complex 
details  of  military  tasks  and  functions  and  the  systems  that 
support  them  might  be  best  viewed  as  a  sort  of  "black  box." 
The  important  things  to  know  are  the  inputs,  outputs,  and 
design  parameters  for  the  processes  inside  the  box.  If  we  get 
these  parameters  right  (the  "knobs"  or  "dials"  on  our  black 
box)  then  we  will  have  designed  a  robust  capability  develop¬ 
ment  system  in  which  the  complex  relationships  of  task  and 
function  to  system  will  likely  self-organize  optimally  without 
our  interference. 

It  will  take  vision  and  leadership  at  the  highest  levels  within 
DoD  to  move  us  to  this  kind  of  model,  but  it  can  be  done. 

The  author  can  be  contacted  at  michael.cochrane@jfcoiti.mil. 
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